home *** CD-ROM | disk | FTP | other *** search
Text File | 1994-08-02 | 89.5 KB | 2,421 lines |
-
-
-
-
- Network Working Group ANSI X3S3.3 86-118
- Request for Comments: 995 ISO TC97/SC6/N 4053
- April 1986
-
-
-
-
-
- I S O
- INTERNATIONAL ORGANIZATION FOR STANDARDIZATION
- ORGANISATION INTERNATIONALE DE NORMALISATION
-
- ______________________________________________________________________
- | |
- | ISO/TC 97/SC 6 |
- | TELECOMMUNICATIONS AND INFORMATION |
- | EXCHANGE BETWEEN SYSTEMS |
- | Secretariat: USA (ANSI) |
- | |
- | |
- |_____________________________________________________________________|
-
-
-
-
-
- Title: End System to Intermediate System Routing Exchange Protocol
- for use in conjunction with ISO 8473
-
- Source: SC6/WG2
- Project 97.6.41
-
-
-
-
- ___________________________________________________________________________
- |This document is a progression of SC6/N3862, edited to incorporate member |
- |body comments and discussion at the Florence meeting of SC6/WG2. Pursuant |
- |to Recommendation 5 of that meeting, comments from member bodies on this |
- |revision text are requested for discussion at the Tokyo meeting of SC6 |
- |and WGs. |
- |__________________________________________________________________________|
-
-
-
-
-
-
-
-
-
-
-
-
- ISO N4053 [Page 1]
-
- RFC 995 December 1986
-
-
- Contents
-
- 1 Introduction 5
-
- 2 Scope and Field of Application 6
-
- 3 References 7
-
-
- SECTION ONE. GENERAL 9
-
- 4 Definitions 9
- 4.1 Reference Model Definitions . . . . . . . . . . . . . . . . . 9
- 4.2 Network Layer Architecture Definitions . . . . . . . . . . . 9
- 4.3 Network Layer Addressing Definitions . . . . . . . . . . . . 9
- 4.4 Local Area Network Definitions . . . . . . . . . . . . . . . 10
- 4.5 Additional Definitions . . . . . . . . . . . . . . . . . . . . 10
-
- 5 Symbols and Abbreviations 10
- 5.1 Data Units . . . . . . . . . . . . . . . . . . . . . . . . . 10
- 5.2 Protocol Data Units . . . . . . . . . . . . . . . . . . . . . 10
- 5.3 Protocol Data Unit Fields . . . . . . . . . . . . . . . . . . 10
- 5.4 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 11
- 5.5 Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . 11
-
- 6 Overview of the Protocol 11
- 6.1 Information Provided by the Protocol . . . . . . . . . . . . . 11
- 6.2 Subsets of the Protocol. . . . . . . . . . . . . . . . . . . . 12
- 6.3 Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 12
- 6.4 Underlying Service Assumed by the Protocol . . . . . . . . . 12
- 6.4.1 Subnetwork Addresses . . . . . . . . . . . . . . . . . 12
- 6.4.2 Subnetwork User Data . . . . . . . . . . . . . . . . . 13
- 6.5 Service Assumed from Local Environment . . . . . . . . . . . . 13
- 6.6 Subnetwork Types . . . . . . . . . . . . . . . . . . . . . . . 14
- 6.6.1 Point-to-Point Subnetworks . . . . . . . . . . . . . . 15
- 6.6.2 Broadcast Subnetworks . . . . . . . . . . . . . . . . 15
- 6.6.3 General Topology Subnetworks . . . . . . . . . . . . . 16
-
-
- SECTION TWO. SPECIFICATION OF THE PROTOCOL 18
-
- 7 Protocol Functions 18
- 7.1 Protocol Timers . . . . . . . . . . . . . . . . . . . . . . . 18
- 7.1.1 Configuration Timer . . . . . . . . . . . . . . . . . 18
- 7.1.2 Holding Timer . . . . . . . . . . . . . . . . . . . . 18
- 7.2 Report Configuration Function . . . . . . . . . . . . . . . . 18
- 7.2.1 Report Configuration by End Systems . . . . . . . . . 19
- 7.2.2 Report Configuration by Intermediate Systems . . . . . 19
- 7.3 Record Configuration Function . . . . . . . . . . . . . . . . 20
- 7.4 Flush Old Configuration Function . . . . . . . . . . . . . . 20
- 7.5 Query Configuration Function . . . . . . . . . . . . . . . . . 20
-
-
-
- ISO N4053 [Page 2]
-
- RFC 995 December 1986
-
-
- 7.6 Configuration Response Function . . . . . . . . . . . . . . . 21
- 7.7 Request Redirect Function. . . . . . . . . . . . . . . . . . . 22
- 7.8 Record Redirect Function . . . . . . . . . . . . . . . . . . . 23
- 7.9 Refresh Redirect Function . . . . . . . . . . . . . . . . . . 23
- 7.10 Flush Old Redirect Function . . . . . . . . . . . . . . . . . 24
- 7.11 PDU Header Error Detection . . . . . . . . . . . . . . . . . 24
- 7.12 Classification of Functions . . . . . . . . . . . . . . . . . 25
-
- 8 Structure and Encoding of PDUs 25
- 8.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 26
- 8.2 Fixed Part . . . . . . . . . . . . . . . . . . . . . . . . . . 26
- 8.2.1 General . . . . . . . . . . . . . . . . . . . . . . . 26
- 8.2.2 Network Layer Protocol Identifier . . . . . . . . . . 27
- 8.2.3 Length Indicator . . . . . . . . . . . . . . . . . . . 27
- 8.2.4 Version/Protocol Identifier Extension . . . . . . . . 27
- 8.2.5 Type Code . . . . . . . . . . . . . . . . . . . . . . 28
- 8.2.6 Holding Time . . . . . . . . . . . . . . . . . . . . . 28
- 8.2.7 PDU Checksum . . . . . . . . . . . . . . . . . . . . . 28
- 8.3 Network Address Part . . . . . . . . . . . . . . . . . . . . . 28
- 8.3.1 General . . . . . . . . . . . . . . . . . . . . . . . 28
- 8.3.2 NPAI (Network Protocol Address Information) En-
- coding . . . . . . . . . . . . . . . . . . . . . . . . 28
- 8.3.3 Source Address Parameter for ESH PDU . . . . . . . . 29
- 8.3.4 Network Entity Title Parameter for ISH PDU . . . . . . 29
- 8.3.5 Destination Address Parameter for RD PDU . . . . . . . 30
- 8.4 Subnetwork Address Part . . . . . . . . . . . . . . . . . . . 30
- 8.4.1 Subnetwork Address Parameter for RD PDU . . . . . . . 31
- 8.5 Options Part . . . . . . . . . . . . . . . . . . . . . . . . . 31
- 8.5.1 General . . . . . . . . . . . . . . . . . . . . . . . 31
- 8.5.2 Security . . . . . . . . . . . . . . . . . . . . . . . 32
- 8.5.3 Quality of Service Maintenance . . . . . . . . . . . . 33
- 8.5.4 Priority . . . . . . . . . . . . . . . . . . . . . . . 33
- 8.6 End System Hello (ESH) PDU . . . . . . . . . . . . . . . . . . 34
- 8.6.1 Structure . . . . . . . . . . . . . . . . . . . . . . 34
- 8.7 Intermediate System Hello (ISH) PDU . . . . . . . . . . . . . 35
- 8.7.1 Structure . . . . . . . . . . . . . . . . . . . . . . 35
- 8.8 Redirect (RD) PDU. . . . . . . . . . . . . . . . . . . . . . . 36
- 8.8.1 Structure . . . . . . . . . . . . . . . . . . . . . . 36
-
- 9 Formal Description 37
-
- 10 Conformance 37
-
- ANNEX A. SUPPORTING TECHNICAL MATERIAL 38
- A.1 Use of Timers . . . . . . . . . . . . . . . . . . . . . . . . 38
- A.1.1 Example of Holding Time for Route Redirection . . . . 38
- A.1.2 Example of Holding Timer for Configuration Informa-
- tion . . . . . . . . . . . . . . . . . . . . . . . . . 39
- A.2 Refresh and timeout of Redirection information . . . . . . . . 39
- A.3 System Initialization Considerations . . . . . . . . . . . . . 40
- A.4 Optimizations for Flushing Redirects . . . . . . . . . . . . 41
-
-
-
- ISO N4053 [Page 3]
-
- RFC 995 December 1986
-
-
- List of Tables
-
- 1 Service Primitives for Underlying Service . . . . . . . . . . 12
- 2 Timer Primitives . . . . . . . . . . . . . . . . . . . . . . . 14
- 3 Categories of Protocol Functions . . . . . . . . . . . . . . . 25
- 4 Valid PDU Types . . . . . . . . . . . . . . . . . . . . . . . 28
-
-
- List of Figures
-
- 1 PDU Header -- Fixed Part . . . . . . . . . . . . . . . . . . . 27
- 2 Address Parameters . . . . . . . . . . . . . . . . . . . . . 29
- 3 ESH PDU - Network Address Part . . . . . . . . . . . . . . . 29
- 4 ISH PDU - Network Address Part . . . . . . . . . . . . . . . . 30
- 5 RD PDU - Network Address Part . . . . . . . . . . . . . . . . 30
- 6 ESH PDU - Address Part . . . . . . . . . . . . . . . . . . . 31
- 7 All PDUs - Options Part . . . . . . . . . . . . . . . . . . . 31
- 8 Encoding of Option Parameters . . . . . . . . . . . . . . . . 32
- 9 ESH PDU Format . . . . . . . . . . . . . . . . . . . . . . . . 34
- 10 ISH PDU Format . . . . . . . . . . . . . . . . . . . . . . . . 35
- 11 RD PDU Format when Redirect is to an IS . . . . . . . . . . . 36
- 12 RD PDU Format when Redirect is to an ES . . . . . . . . . . . 37
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- ISO N4053 [Page 4]
-
- RFC 995 December 1986
-
-
- 1 Introduction
-
- This Protocol is one of a set of International Standards produced to
- facilitate the interconnection of open systems. The set of standards
- covers the services and protocols required to achieve such intercon-
- nection.
-
- This Protocol is positioned with respect to other related standards
- by the layers defined in the Reference Model for Open System Inter-
- connection (ISO 7498) and by the structure defined in the Internal
- Organization of the Network Layer (DIS 8648). In particular, it is a
- protocol of the Network Layer. This protocol permits End Systems and
- Intermediate Systems to exchange configuration and routing informa-
- tion to facilitate the operation of the routing and relaying func-
- tions of the Network Layer.
-
- The aspects of Network Layer routing that are concerned with communi-
- cation between end systems and intermediate systems on the same sub-
- network are to a great extent separable from the aspects that are
- concerned with communication among the intermediate systems that con-
- nect multiple subnetworks. This protocol addresses only the former
- aspects. It will be significantly enhanced by the cooperative opera-
- tion of an additional protocol that provides for the exchange of
- routing information among intermediate systems, but is useful whether
- or not such an additional protocol is available.
-
- This protocol provides solutions for the following practical problems:
-
- 1. How do end systems discover the existence and reachability of
- intermediate systems that can route NPDUs to destinations on
- subnetworks other than the one(s) to which the end system is
- directly connected?
-
- 2. How do end systems discover the existence and reachability of
- other end systems on the same subnetwork (when direct
- examination of the destination NSAP address does not provide
- information about the destination subnetwork)?
-
- 3. How do intermediate systems discover the existence and
- reachability of end systems on each of the subnetworks to
- which they are directly connected?
-
- 4. How do end systems decide which intermediate system to use
- to forward NPDUs to a particular destination when more than one
- intermediate system is accessible?
-
- The protocol assumes that:
-
- 1. Routing to a specified subnetwork point of attachment address
- (SNPA) on the same subnetwork is carried out satisfactorily by
- the subnetwork itself.
-
-
-
- ISO N4053 [Page 5]
-
- RFC 995 December 1986
-
-
- 2. The subnetwork is not, however, capable of routing on a global
- basis using the NSAP address alone to achieve communication
- with a requested destination.
-
- Note:
- Consequently, it is not possible to use Application Layer
- communication to carry out the functions of this protocol.
-
- The protocol is connectionless, and is designed to:
-
- 1. minimize the amount of a priori state information needed by
- end systems before they can begin to communicate with other
- end systems;
-
- 2. minimize the amount of memory needed to store routing
- information in end systems; and
-
- 3. minimize the computational complexity of end system routing
- algorithms.
-
-
- The protocol is also designed to operate in close conjunction with
- the Protocol for the Provision of the Connectionless-mode Network
- Service (ISO 8473). Since routing styles are usually closely related
- to communication styles, the information that this protocol provides
- to end systems and intermediate systems may or may not be appropriate
- information for supporting routing functions when a Network Layer
- protocol other than ISO 8473 is used.
-
- 2 Scope and Field of Application
-
- This International Standard specifies a protocol which is used by
- Network Layer entities operating ISO 8473 in End Systems and Inter-
- mediate Systems (referred to herein as ES and IS respectively) to
- maintain routing information. The Protocol herein described relies
- upon the provision of a connectionless-mode underlying service.
-
- This Standard specifies:
-
- a) procedures for the transmission of configuration and routing
- information between network entities residing in End Systems
- and network entities residing in Intermediate Systems;
-
- b) the encoding of the protocol data units used for the transmission
- of the configuration and routing information;
-
- c) procedures for the correct interpretation of protocol control
- information; and
-
- d) the functional requirements for implementations claiming
- conformance to this Standard.
-
-
-
- ISO N4053 [Page 6]
-
- RFC 995 December 1986
-
-
- The procedures are defined in terms of:
-
- a) the interactions between End System and Intermediate System
- network entities through the exchange of protocol data units;
- and
-
- b) the interactions between a network entity and an underlying
- service provider through the exchange of subnetwork service
- primitives.
-
- This protocol does not specify any protocol elements or algorithms for
- facilitating routing and relaying among Intermediate Systems. Such
- functions are intentionally beyond the scope of this protocol.
-
- 3 References
-
-
- ISO 7498 Information Processing Systems --- Open Systems Intercon-
- nection - Basic Reference Model
-
- DIS 7498/DAD1 Information Processing Systems --- Open Systems Intercon-
- nection - Addendum to ISO 7498 Covering Connectionless-
- mode Transmission
-
- ISO 8348 Information Processing Systems --- Telecommunications and
- Information Exchange between Systems - Network Service
- Definition
-
- ISO 8348/AD1 Information Processing Systems --- Telecommunications and
- Information Exchange between Systems - Addendum to the
- Network Service Definition Covering Connectionless-mode
- Transmission
-
-
- ISO 8348/AD2 Information Processing Systems --- Telecommunications and
- Information Exchange between Systems - Addendum to the
- Network Service Definition Covering Network Layer Address-
- ing
-
-
- ISO 8473 Information Processing Systems --- Telecommunications and
- Information Exchange between Systems - Protocol for Pro-
- viding the Connectionless Network Service
-
-
- DIS 8648 Information Processing Systems --- Telecommunications and
- Information Exchange between Systems - Internal Organiza-
- tion of the Network Layer
-
-
-
-
-
-
- ISO N4053 [Page 7]
-
- RFC 995 December 1986
-
-
- SC21/N965 OSI Management Framework --- Seventh Working Draft
-
- DIS 8802 Local Area Networks
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- ISO N4053 [Page 8]
-
- RFC 995 December 1986
-
-
- SECTION ONE. GENERAL
-
- 4 Definitions
-
- 4.1 Reference Model Definitions
-
- This document makes use of the following concepts defined in ISO 7498:
-
- (a) Network layer
-
- (b) Network service access point
-
- (c) Network service access point address
-
- (d) Network entity
-
- (e) Routing
-
- (f) Network protocol
-
- (g) Network relay
-
- (h) Network protocol data unit
-
- 4.2 Network Layer Architecture Definitions
-
- This document makes use of the following concepts from DIS 8648, Internal
- Organization of the Network Layer:
-
- (a) Subnetwork
-
- (b) End System
-
- (c) Intermediate System
-
- (d) Subnetwork Service
-
- (e) Subnetwork Access Protocol
-
- (f) Subnetwork Independent Convergence Protocol
-
- 4.3 Network Layer Addressing Definitions
-
- This document makes use of the following concepts from DIS 8348/DAD2,
- Addendum to the Network Service Definition Covering Network Layer Ad-
- dressing:
-
-
- (a) Subnetwork address
-
- (b) Subnetwork point of attachment
-
-
-
- ISO N4053 [Page 9]
-
- RFC 995 December 1986
-
-
- 4.4 Local Area Network Definitions
-
- This document makes use of the following concepts from DIS 8802, Local
- Area Networks:
-
- (a) multicast address
-
- (b) broadcast medium
-
- 4.5 Additional Definitions
-
- For the purposes of this document, the following definitions apply:
-
- Configuration: The collection of End and Intermediate Systems
- attached to a single subnetwork, defined in terms of the
- system types, NSAP addresses present, Network Entities
- present, and the correspondence between systems and SNPA
- addresses.
-
- Network Entity Title: An identifier for a network entity which
- has the same abstract syntax as an NSAP address, and which
- can be used to unambiguously identify a network entity in
- an End or Intermediate System.
-
- 5 Symbols and Abbreviations
-
- 5.1 Data Units
- PDU Protocol Data Unit
- SNSDU Subnetwork Service Data Unit
-
- 5.2 Protocol Data Units
-
- ESH PDU End System Hello Protocol Data Unit
- ISH PDU Intermediate System Hello Protocol Data Unit
- RD PDU Redirect Protocol Data Unit
-
- 5.3 Protocol Data Unit Fields
-
- NPID Network Layer Protocol Identifier
- LI Length Indicator
- V/P Version/Protocol Identifier Extension
- TP Type
- CS Checksum
- NETL Network entity Title Length
- NET Network entity Title
- DAL Destination Address Length
- DA Destination Address
- SAL Source Address Length
- SA Source Address
- BSNPAL SN Address Length of better route to destination
- BSNPA SN Address of better route to destination
-
-
-
- ISO N4053 [Page 10]
-
- RFC 995 December 1986
-
-
- HT Holding timer
-
- 5.4 Parameters
- CT Configuration Timer
- RT Redirect Timer
-
- 5.5 Miscellaneous
-
- ES End System
- IS Intermediate System
- SN Subnetwork
- SNACP Subnetwork Access Protocol
- SNICP Subnetwork Independent Convergence Protocol
-
- 6 Overview of the Protocol
-
- 6.1 Information Provided by the Protocol
-
- This Protocol provides two types of information to Network entities
- which support its operation:
-
- a) Configuration Information, and
-
- b) Route Redirection Information
-
- Configuration Information permits End Systems to discover the ex-
- istence and reachability of Intermediate Systems and permits Inter-
- mediate Systems to discover the existence and reachability of End
- Systems. This information allows ESs and ISs attached to the same
- subnetwork to dynamically discover each other's existence and availa-
- bility, thus eliminating the need for manual intervention at ESs and
- ISs to establish the identity of Network entities that can be used to
- route NPDUs.
-
- Configuration Information also permits End Systems to obtain informa-
- tion about each other in the absence of an available Intermediate
- System.
-
- Note:
- The term "configuration information" is not intended in the broad
- sense of configuration as used in the context of OSI system
- management. Rather, only the functions specifically defined herein
- are intended.
-
- Route Redirection Information allows Intermediate Systems to inform
- End Systems of (potentially) better paths to use when forwarding
- NPDUs to a particular destination. A better path could either be
- another IS on the same subnetwork as the ES, or the destination ES
- itself, if it on the same subnetwork as the source ES. Allowing the
- ISs to inform the ESs of routes minimizes the complexity of routing
- decisions in End Systems and improves performance because the ESs may
-
-
-
- ISO N4053 [Page 11]
-
- RFC 995 December 1986
-
-
- make use of the better IS or local subnetwork access for subsequent
- transmissions.
-
- 6.2 Subsets of the Protocol
-
- A Network Entity may choose to support either the Configuration In-
- formation, the Route Redirection Information, neither, or both. If
- the Configuration Information is supported, it is not required that
- it be employed over all subnetworks to which the Network entity is
- attached.
-
- 6.3 Addressing
-
- The Source Address and Destination Address parameters referred to in
- this International Standard are OSI Network Service Access Point Ad-
- dresses. The syntax and semantics of an OSI Network Service Access
- Point Address are described in a separate document, ISO 8348/DAD2,
- Addendum to the Network Service Definition covering Network Layer Ad-
- dressing.
-
- 6.4 Underlying Service Assumed by the Protocol
-
- The underlying service required to support this protocol is defined
- by the primitives in Table 1.
-
- _________________________________________________________________
- | SN_UNITDATA .Request | SN_Destination_Address, |
- | .Indication | SN_Source_Address, |
- | | SN_Quality_of_Service, |
- | | SN_Userdata |
- |_____________________________________|_________________________|
-
- Table 1: Service Primitives for Underlying Service
-
-
-
- Note:
- These service primitives are used to describe the abstract interface
- which exists between the protocol machine and an underlying real
- subnetwork or a Subnetwork Dependent Convergence Function which
- operates over a real subnetwork or real data link to provide the
- required underlying service.
-
- 6.4.1 Subnetwork Addresses
-
- The source and destination addresses specify the points of attachment
- to a public or private subnetwork(s) involved in the transmission
- (known as Subnetwork Points of Attachment, or SNPAs).Subnetwork ad-
- dresses are defined in the Service Definition of each individual sub-
- network. This protocol is designed to take advantage of subnetworks
- which support broadcast, multicast, or other forms of multi-
-
-
-
- ISO N4053 [Page 12]
-
- RFC 995 December 1986
-
-
- destination addressing for n-way transmission. It is assumed that the
- SN_Destination_Address parameter may take on one of the following
- multi-destination addresses in addition to a normal single destina-
- tion address:
-
- All End System Network entities
-
- All Intermediate System Network entities
-
- Where a real subnetwork does not inherently support broadcast or oth-
- er forms of transmission to multi-destination addresses, a conver-
- gence function may be used to provide n-way transmission to these
- multi-destination addresses.
-
- When the SN_Destination_Address on the SN_UNITDATA.Request is a
- multi-destination address, the SN_Destination_Address parameter in
- the corresponding SN_UNITDATA.Indication shall be the same multi-
- destination address.
-
- The syntax and semantics of subnetwork addresses, except for the pro-
- perties described above, are not defined in this Protocol Standard.
-
- 6.4.2 Subnetwork User Data
-
- The SN_Userdata is an ordered multiple of octets, and is transferred
- transparently between the specified subnetwork points of attachment.
-
- The underlying service is required to support a service data unit
- size of at least that required to operate the Protocol for Providing
- the Connectionless Network Service (ISO 8473).
-
- 6.5 Service Assumed from Local Environment
-
- A timer service must be provided to allow the protocol entity to
- schedule events.
-
- There are three primitives associated with the S-TIMER service:
-
- 1. the S--TIMER Request,
- 2. the S--TIMER Response, and
- 3. the S--TIMER Cancel.
-
- The S--TIMER Request primitive indicates to the local environment
- that it should initiate a timer of the specified name and subscript
- and maintain it for the duration specified by the time parameter.
-
- The S--TIMER Response primitive is initiated by the local environment
- to indicate that the delay requested by the corresponding S-TIMER Re-
- quest primitive has elapsed.
-
- The S--TIMER Cancel primitive is an indication to the local environ-
-
-
-
- ISO N4053 [Page 13]
-
- RFC 995 December 1986
-
-
- ment that the specified timer(s) should be canceled.If the subscript
- parameter is not specified, then all timers with the specified name
- are canceled; otherwise, the timer of the given name and subscript is
- cancelled. If no timers correspond to the parameters specified, the
- local environment takes no action.
-
- The parameters of the S--TIMER service primitives are specified in
- Table 2.
-
- ___________________________________________
- | | |
- | S--TIMER .Request | S-Time, |
- | | S-Name, |
- | | S-Subscript |
- | | |
- | .Response | S-Name, |
- | | S-Subscript |
- |__________________________|_______________|
-
- Table 2: Timer Primitives
-
- The time parameter indicates the time duration of the specified ti-
- mer. An identifiying label is associated with a timer by means of
- the name parameter.The subscript parameter specifies a value to dis-
- tinguish timers with the same name. The name and subscript taken to-
- gether constitute a unique reference to the timer.
-
- Timers used in association with a specific protocol funtion are de-
- fined under that protocol function.
-
- Note:
- This International Standard does not define specific values for the
- timers.Any derivations described in this Standard are not mandatory.
- Timer values should be chosen so that the requested Quality of
- Service can be provided, given the known characteristics of the
- underlying service.
-
- 6.6 Subnetwork Types
-
- In order to evaluate the applicability of this protocol in particular
- configurations of End Systems, Intermediate Systems and subnetworks,
- three generic types of subnetwork are identified. These are:
-
- 1. the point-to-point subnetwork,
-
- 2. the broadcast subnetwork, and
-
- 3. the general topology subnetwork
-
- These subnetwork types are discussed in the following clauses.
-
-
-
-
- ISO N4053 [Page 14]
-
- RFC 995 December 1986
-
-
- 6.6.1 Point-to-Point Subnetworks
-
- A point-to-point subnetwork supports exactly two systems. The two
- systems may be either two End Systems, or an End System and a single
- Intermediate System. A single point-to-point data link connecting two
- Network Entities is an example of a point-to-point subnetwork.
-
-
- Configuration Information on a point-to-point Subnetwork.On a point-
- to-point subnetwork the Configuration Information of this protocol
- informs the communicating Network entities of the following:
-
- 1. Whether the topology consists only of two End Systems, or
-
- 2. One of the two systems is a Intermediate System.
-
- Note:
- On a point-to-point subnetwork, if both systems are Intermediate Systems,
- then this protocol is inapplicable to the situation, since a IS-to-IS
- protocol should be employed instead. However, there is no reason why
- the configuration information could not be employed in a IS-to-IS
- environment to ascertain the topology and initiate operation of a
- IS-to-IS protocol.
-
- The Intermediate System is informed of the NSAP address(es) supported
- by the Network entity in the End System. This permits reachability
- information and routing metrics concerning these NSAPs to be dissem-
- inated to other Intermediate Systems for the purpose of calculating
- routes to/from this End System.
-
- Route Redirection Information on a point-to-point Subnetwork. Route
- Redirection Information is not employed on point-to-point subnetworks
- because there are never any alternate routes.
-
- 6.6.2 Broadcast Subnetworks
-
- A Broadcast subnetwork supports an arbitrary number of End Systems
- and Intermediate Systems, and additionally is capable of transmitting
- a single SNPDU to all or a subset of these systems in response to a
- single SN_UNITDATA.Request.An example of a broadcast subnetwork is a
- LAN (local area network) conforming to DIS8802/2, type 1 operation.
-
-
- Configuration Information on a broadcast Subnetwork.On a broadcast
- subnetwork the Configuration Information of this protocol is employed
- to inform the communicating Network entities of the following:
-
- 1. End Systems are informed of the reachability, Network entity Title,
- and SNPA address(es) of each active Intermediate System on the
- subnetwork.
-
-
-
-
- ISO N4053 [Page 15]
-
- RFC 995 December 1986
-
-
- 2. Intermediate Systems are informed of the NSAP addresses supported
- by each End System and the Subnetwork address of the ES. Once the
- Intermediate System obtains this information, reachability
- information and routing metrics concerning these NSAPs may be
- disseminated to other ISs for the purpose of calculating routes
- to/from each ES on the subnetwork.
-
- 3. In the absence of an available Intermediate System, End Systems may
- query over a broadcast subnetwork to discover whether a particular
- NSAP is reachable on the subnetwork, and if so, what SNPA address
- to use to reach that NSAP.
-
- Route Redirection Information on broadcast Subnetworks.Route Redirec-
- tion Information may be employed on broadcast subnetworks to permit
- Intermediate Systems to inform End Systems of superior routes to a
- destination NSAP. The superior route might be another IS on the same
- subnetwork as the ES, or it might be the destination ES itself, if it
- is directly reachable on the same subnetwork as the source ES.
-
- 6.6.3 General Topology Subnetworks
-
- A general topology subnetwork supports an arbitrary number of End
- Systems and Intermediate Systems, but does not support a convenient
- multidestination connectionless transmission facility as does a
- broadcast subnetwork.An example of a general topology subnetwork is a
- subnetwork employing X.25 or ISO 8208.
-
- Note:
- The crucial distinguishing characteristic between the broadcast
- subnetwork and the general topology subnetwork is the "cost" of an
- n-way transmission to a potentially large subset of the systems on
- the subnetwork. On a general topology subnetwork, the cost is assumed
- to be close to the cost of sending an individual PDU to each SNPA on
- the subnetwork. Conversely, on a broadcast subnetwork the cost is
- assumed to be close to the cost of sending a single PDU to one SNPA
- on the subnetwork. Intermediate situations between these extremes
- are of course possible. In such cases it would be possible to treat the
- subnetwork as either in the broadcast or general topology categories.
-
- Configuration Information on a general topology Subnetwork. On a
- general topology subnetwork the Configuration Information is general-
- ly not employed because this protocol can be very costly in the util-
- ization (and charging for) subnetwork resources.
-
-
- Route Redirection Information on a general topology Subnetwork.
- Route Redirection Information may be employed on general topology
- subnetworks to permit Intermediate Systems to inform End Systems of
- superior routes to a destination NSAP. The superior route might be
- another IS on the same subnetwork as the ES, or it might be the des-
- tination ES itself, if it is directly reachable on the same subnet-
-
-
-
- ISO N4053 [Page 16]
-
- RFC 995 December 1986
-
-
- work as the source ES.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- ISO N4053 [Page 17]
-
- RFC 995 December 1986
-
-
- SECTION TWO. SPECIFICATION OF THE PROTOCOL
-
- 7 Protocol Functions
-
- This section describes the functions performed as part of the Proto-
- col. Not all of the functions must be performed by every implementa-
- tion. Clause 7.12 specifies which functions may be omitted and the
- correct behavior where requested functions are not implemented.
-
- 7.1 Protocol Timers
-
- Many of the protocol functions are timer based. This means that they
- are executed upon expiration of a timer rather than upon receipt of a
- PDU or invocation of a service primitive. The two major types of ti-
- mers employed by the protocol are the Configuration Timer (CT) and
- the Holding Timer (HT).
-
- 7.1.1 Configuration Timer
-
- The Configuration Timer is a local timer (i.e. maintained indepen-
- dently by each system) which performs the Report Configuration func-
- tion (see section 7.2). The timer determines how often a system re-
- ports its availability to the other systems on the same subnetwork.
- The shorter the Configuration Timer, the more quickly other systems
- on the subnetwork will become aware when the reporting system becomes
- available or unavailable. The increased responsiveness must be traded
- off against increased use of resources in the subnetwork and in the
- recipient systems.
-
- 7.1.2 Holding Timer
-
- The Holding Timer applies to both Configuration Information and Route
- Redirection Information. The value of the Holding Timer is set by the
- source of the information and transmitted in the appropriate PDU. The
- recipient of the information is expected to retain the information no
- longer than the Holding Timer. Old Configuration or Route Redirection
- information must be discarded after the Holding Timer expires to en-
- sure the correct operation of the protocol.
-
- Further discussion of the rationale for these timers and guidelines
- for their use may be found in annex 10.
-
- 7.2 Report Configuration Function
-
- The Report Configuration Function is used by End Systems and Inter-
- mediate Systems to inform each other of their reachability and
- current subnetwork address. This function is invoked every time the
- local Configuration Timer (CT) expires in an ES or IS. It is also in-
- voked upon receipt of a Query Configuration PDU from another End Sys-
- tem.
-
-
-
-
- ISO N4053 [Page 18]
-
- RFC 995 December 1986
-
-
- 7.2.1 Report Configuration by End Systems
-
- An End System constructs and transmits one ESH PDU (ESH stands for
- "End System Hello") for each NSAP it serves, and issues one
- SN_UNITDATA.- Request with the ESH PDU as the SNSDU on each subnet-
- work to which it is attached.
-
- Note:
- The necessity to transmit a separate ESH PDU for each NSAP served by
- the Network entity arises from the lack of a formalized relationship
- between Network Entity Titles and NSAP addresses. If this relationship
- could be constrained to require that all NSAP addresses be assigned as
- leaf subdomains of a domain represented by the local Network entity's
- Network entity Title, then a single ESH PDU could be transmitted
- containing the ESs Network entity Title.The Network entity Title
- would then imply which NSAPs might be present at that End system.
-
- The Holding Timer (HT) field is set to approximately twice the ESs
- Configuration Timer (CT) parameter. This variable is set to a value
- large enough so that even if every other ESH PDU is discarded (due to
- lack of resources), or otherwise lost in the subnetwork, the confi-
- guration information will still be maintained. The value must be set
- small enough so that Intermediate Systems can respond in a timely
- fashion to End Systems becoming available or unavailable.
-
- The SN_Destination_Address parameter is set to the group address that
- indicates "All Intermediate System Network Entities". This ensures
- that a single transmission on a broadcast subnetwork will reach all
- of the active Intermediate Systems.
-
- Note:
- The actual value of the SN_Destination_Address used to mean "All
- Intermediate System Network Entities" is subnetwork dependent and will
- most likely vary from subnetwork to subnetwork. It would of course be
- desirable that on widely-used subnetwork types (such as those based
- on DIS 8802) that this value and the value of the "All End System
- Network Entities" group address, be standardized.
-
- 7.2.2 Report Configuration by Intermediate Systems
-
- An Intermediate System constructs a single ISH PDU (ISH stands for
- "Intermediate System Hello") containing the ISs Network Entity Title
- and issues one SN_UNITDATA.Request with the ISH PDU as the SNSDU on
- each subnetwork to which it is attached.
-
- The Holding Timer (HT) field is set to approximately twice the Inter-
- mediate System's Configuration Timer (CT) parameter. This variable is
- set to a value large enough so that even if every other ISH PDU is
- discarded (due to lack of resources), or otherwise lost in the sub-
- network, the configuration information will still be maintained.The
- value must be set small enough so that End Systems will quickly cease
-
-
-
- ISO N4053 [Page 19]
-
- RFC 995 December 1986
-
-
- to use ISs that have failed, thus preventing "black holes" in the
- Network.
-
- The SN_Destination_Address parameter is set to the group address that
- indicates "All End System Network Entities".This ensures that a sin-
- gle transmission on a broadcast subnetwork will reach all of the ac-
- tive End Systems.
-
- 7.3 Record Configuration Function
-
- The Record Configuration function receives ESH or ISH PDUs, extracts
- the configuration information, and adds or replaces the corresponding
- configuration information in the local Network entity's Routing In-
- formation base. If insufficient space is available to store new con-
- figuration information, the PDU is discarded. No Error Report is gen-
- erated.
-
- Note:
- The protocol is described such that End Systems receive and record
- only ISH PDUs and Intermediate Systems receive and process only
- ESH PDUs. If an ES so desires however, it may decide to process ESH
- PDUs as well (on a broadcast network this is easily done by enabling
- the appropriate group address). There is potentially some performance
- improvement to be gained by doing this, at the expense of extra memory,
- and possibly extra processing cycles in the End System.The
- ES, by recording other ESs' Configuration information, may be able
- to route NPDUs directly to ESs on the local subnetwork without first
- being redirected by a Intermediate System.
-
- Similarly, Intermediate Systems may choose to receive the ISH PDUs
- of other ISs, allowing this protocol to be used as the initialization and
- topology maintenance portion of a full IS-to-IS routing protocol.
- Both of these possibilities are for further study.
-
- 7.4 Flush Old Configuration Function
-
- The Flush Old Configuration Function is executed to remove Configura-
- tion entries in the routing information base whose Holding Timer has
- expired. When the Holding Time for an ES or IS expires, this func-
- tion removes the corresponding entry from the routing information
- base of the local Network Entity.
-
- 7.5 Query Configuration Function
-
- The Query Configuration Function is performed under the following
- circumstances:
-
- 1. The End System is attached to a broadcast subnetwork,
-
- 2. There is no Intermediate System currently reachable on the
- subnetwork (i.e. no ISH PDUs have been received since the last
-
-
-
- ISO N4053 [Page 20]
-
- RFC 995 December 1986
-
-
- information was flushed by the Flush Old Configuration Function),
-
- 3. The Network Layer's Route PDU Function needs to obtain the SNPA
- address to which to forward a PDU destined for a certain NSAP, and
-
- 4. The SNPA address cannot be obtained either by a local transformation
- or a local table lookup.
-
- Note:
- Despite appearances, this is actually a quite common case, since it
- is likely that there will be numerous isolated Local Area Networks
- without Intermediate Systems to rely upon for obtaining routing
- information (e.g.via the Request Redirect Function of this protocol).
- Further, if the Intermediate System(s) are temporarily unavailable,
- without this capability communication on the local subnetwork would
- suffer unless manually-entered tables were present in each End System
- or all NSAPs of the subnetwork had the subnetwork SNPA address
- embedded in them.
-
- The End System, when needing to route an NPDU to a destination NSAP
- whose SNPA is unknown issues an SN_UNITDATA.Request with the NPDU as
- the SN_Userdata.The SN_Destination_Address parameter is set to the
- group address that indicates "All End System Network Entities".
-
- Subsequently an ESH PDU may be received containing the NSAP address
- along with the corresponding SNPA address (see clause 7.6). In such a
- case the End System executes the Record Configuration function for
- the NSAP, and therefore will be able to route subsequent PDUs to that
- destination using the specified SNPA. If no ESH PDU is received, the
- End System may declare the destination NSAP is not reachable. The
- length of time to wait for a response before indicating a failure or
- the possibility of repeating the process some number of times before
- returning a failure are local matters and are not specified in this
- standard.
-
- 7.6 Configuration Response Function
-
- The Configuration Response function is performed when an End System
- attached to a broadcast subnetwork receives an NPDU addressed to one
- of its NSAPs, with the SN_Destination_Address from the
- SN_UNITDATA.Indication set to the group address "All End System
- Netowrk Entities". This occurs as a result of another ES having per-
- formed the Query Configuration function described in clause 7.5.
-
- The End System constructs an ESH PDU identical in content to the ESH
- PDU constructed by the Report Configuration function (see clause
- 7.2.1) for the NSAP to which the received NPDU was addressed.It then
- transmits the ESH PDU to the source of the original NPDU by issuing
- an SN_UNITDATA.Request with the SN_Destination_Address set to the
- value of the SN_Source_Address received in the SN_UNITDATA.Indication
- with the original NPDU.
-
-
-
- ISO N4053 [Page 21]
-
- RFC 995 December 1986
-
-
- 7.7 Request Redirect Function
-
- The Request Redirect Function is present only in Intermediate Systems
- and is closely coupled with the Routing and Relaying Functions of In-
- termediate Systems. The Request Redirect Function is coupled with the
- "Route PDU Function" described in clause 6.5 of ISO 8473. The Request
- Redirect Function is performed after the Route PDU function has cal-
- culated the next hop of the Data PDU's path.
-
- When an NPDU is to be forwarded by a Intermediate System, the Request
- Redirect Function first examines the SN_Source_Address associated
- with the SN_UNITDATA.Indication which received the SNSDU (containing
- this NPDU). If the SN_Source_Address is not from an End System on the
- local subnetwork (determined by examining the Configuration informa-
- tion obtained through the Record Configuration Function), then this
- function does no further processing of the NPDU.
-
- If the NPDU was received directly from an ES the output of the ISs
- Routing and Relaying function for this NPDU is examined. This output
- will contain, among other things, the following pieces of informa-
- tion:
-
- 1. a local identifier for the subnetwork over which to forward the NPDU,
- plus either
-
- 2. the Network entity title and subnetwork address of the IS to which to
- forward the NPDU, or
-
- 3. the subnetwork address of the destination End System.
-
- The Request Redirect function must now determine if the source ES
- could have sent the NPDU directly to the Network entity the Inter-
- mediate System is about to forward the PDU to. If any of the follow-
- ing conditions hold, the source ESshould be informed of the "better"
- path (by sending an RD PDU to the originating ES):
-
- 1. The next hop is to the destination system, and the destination is
- directly reachable (at subnetwork address BSNPA) on the source ESs
- subnetwork, or
-
- 2. The next hop is to a Intermediate System which is connected to the
- same subnetwork as the ES.
-
- If the better path exists, the IS first completes normal processing
- of the received NPDU and forwards it.It then constructs a Redirect
- PDU (RD PDU) containing the Destination Address of the original NPDU,
- the subnetwork address of the better next hop (BSNPA), the Network
- Entity Title of the IS to which the ES is being redirected (unless
- the redirect is to the destination ES), a Holding Time (HT), QoS
- Maintenance, Priority, and Security options that were present in the
- Data NPDU (these are simply copied from the Data PDU). The HT is set
-
-
-
- ISO N4053 [Page 22]
-
- RFC 995 December 1986
-
-
- to the value of the local Redirect Timer (RT). See Annex A for a dis-
- cussion of how to choose the value of RT. If there are insufficient
- resources to both forward the original NPDU and to generate and send
- an RD PDU, the original NPDU must be given preference. The Inter-
- mediate System (assuming it has sufficient resources) then sends the
- RD PDU to the source End System using the SN_Source_Address of the
- received NPDU as the SN_Destination_Address for the SN_UNITDATA.-
- Reqeust.
-
- 7.8 Record Redirect Function
-
- The Record Redirect Function is present only in End Systems. This
- function is invoked whenever an RD PDU is received. It extracts the
- redirect information and adds or replaces the corresponding redirec-
- tion information in the local Network entity's Routing Information
- base. The essential information is the redirection mapping from a
- Destination Address to a subnetwork address, along with the Priority,
- Security, and QoS Maintenance options and the Holding Time for which
- this mapping is to be considered valid. If the Redirect was to anoth-
- er Intermediate System, the Network Entity Title of the IS is record-
- ed as well.
-
- Note:
- If insufficient memory is available to store new redirection information,
- the RD PDU may be safely discarded since the original Intermediate
- System will continue to forward PDUs on behalf of this Network entity
- anyway.
-
- 7.9 Refresh Redirect Function
-
- The Refresh Redirect Function is present only in End Systems. This
- function is invoked whenever an NPDU is received by a destination ES.
- It is closely coupled with the function that processes received NPDUs
- at a destination Network Entity.This is the "PDU Decomposition" func-
- tion in ISO 8473. The purpose of this function is to increase the
- longevity of a redirection without allowing an incorrect route to
- persist indefinitely. The Source Address (SA), Priority, Security,
- and QoS options are extracted and compared to any Destination Address
- and QoS parameters being maintained in the Routing Information base
- (such information would have been stored by the Record Redirect Func-
- tion). If a corresponding entry is found, the previous hop of the PDU
- is obtained from the SN_Source_Address parameter of the
- SN_Unitdata.Indication primitive by which it was received. If this
- address matches the next hop address stored with the redirection in-
- formation, the remaining holding time for the redirection is reset to
- the original holding timer that was obtained from the RD PDU.
-
- Note:
- The purpose of this function is to avoid timing out redirection entries
- when the Network entity is receiving return traffic from the destination
- via the same path over which it is currently sending traffic.This is
-
-
-
- ISO N4053 [Page 23]
-
- RFC 995 December 1986
-
-
- particularly useful when the destination system is on the same subnetwork
- as the source, since after one redirect no IS need be involved in
- the ES-to-ES traffic.
-
- This function must operate in a very conservative fashion however,
- to prevent the formation of black holes. The remaining holding time
- should be refreshed only under the exact conditions specified above.
- For a discussion of the issues surrounding the refresh of redirection
- information, see Annex 10.
-
- 7.10 Flush Old Redirect Function
-
- The Flush Old Redirect Function is executed to remove Configuration
- entries in the routing information base whose Holding Timer has ex-
- pired. When the Holding Time for an ES or IS expires, this function
- removes the corresponding entry from the routing information base of
- the local Network Entity.
-
- 7.11 PDU Header Error Detection
-
- The PDU Header Error Detection function protects against failure of
- Intermediate or End System Network entities due to the processing of
- erroneous information in the PDU header.The function is realized by a
- checksum computed on the entire PDU header. The checksum is verified
- at each point at which the PDU is processed. If the checksum calcula-
- tion fails, the PDU must be discarded.
-
- The use of the Header Error Detection function is optional and is
- selected by the originating Network Entity. If the function is not
- used, the checksum field of the PDU header is set to zero.
-
- If the function is selected by the originating Network Entity, the
- value of the checksum field causes the following formulf to be satis-
- fied:
-
- (The Sum from i=1 to L of a(i)) (mod 255) = 0
-
- (The Sum from i=1 to L of (L - i + 1) * a(i)) (mod 255) = 0
-
-
- where L = the number of octets in the PDU header, and a(i) = the value of
- the octet at position i. The first octet in the PDU header is considered to
- occupy position i = 0.
-
- When the function is in use, neither octet of the checksum field may be
- set to zero.
-
-
-
-
-
-
-
-
- ISO N4053 [Page 24]
-
- RFC 995 December 1986
-
-
- 7.12 Classification of Functions
-
- Implementations do not have to support all of the functions described
- in clause 7. Functions are divided into four categories:
-
- Type A: These functions must be supported in all cases.
-
- Type B: These functions must be supported by Systems which implement
- the Configuration Information.
-
- Type C: These functions must be supported by Systems which implement
- the Redirect Information.
-
- Type D: These functions are optional.
-
- If a PDU is received which invokes an optional function that is not
- implemented, that PDU is discarded.
-
- Table 3 shows how the functions are divided into these four
- categories, and to which type of system (ES, IS, or both) they apply.
-
- ______________________________________________________________
- | Function | Category | System Type |
- |_______________________________|____________|_______________|
- | Report Configuration | B | ES,IS |
- | Record Configuration | B | ES,IS |
- | Configuration Response | A | ES |
- | Flush Old Configuration | B | ES,IS |
- | Request Redirect | C | IS |
- | Query Configuration | B | ES |
- | Record Redirect | C | ES |
- | Refresh Redirect | D | ES |
- | Flush Old Redirect | C | ES |
- | PDU Header Error Detection | A | ES,IS |
- |_______________________________|____________|_______________|
-
- Table 3: Categories of Protocol Functions
-
- 8 Structure and Encoding of PDUs
-
- Note:
- The encoding of the PDUs for this protocol is compatible with that
- used in ISO 8473.
-
- Temporary Note:
- The method employed for describing the encoding of PDUs is provisional.
- Member bodies are requested to comment on whether another
- method (such as ASN.1 with an appropriate concrete syntax) would
- be preferable.
-
-
-
-
-
- ISO N4053 [Page 25]
-
- RFC 995 December 1986
-
-
- 8.1 Structure
-
- All Protocol Data Units shall contain an integral number of
- octets.The octets in a PDU are numbered starting from one (1) and in-
- creasing in the order in which they are put into an SNSDU. The bits
- in an octet are numbered from one (1) to eight (8), where bit one (1)
- is the low-order bit. When consecutive octets are used to represent
- a binary number, the lower octet number has the most significant
- value.
-
- Any subnetwork supporting this protocol is required to state in its
- specification the way octets are transferred, using the terms "most
- significant bit" and "least significant bit". The PDUs of this proto-
- col are defined using the terms "most significant bit" and "least
- significant bit".
-
- Note:
- When the encoding of a PDU is represented using a diagram in this
- section, the following representation is used:
-
- a) octets are shown with the lowest numbered octet to the left,
- higher number octets being further to the right;
- b) within an octet, bits are shown with bit eight (8) to the left and
- bit one (1) to the right.
-
- PDUs shall contain, in the following order:
-
- 1. the fixed part;
-
- 2. the Network address part;
-
- 3. the Subnetwork address part, if present; and
-
- 4. the Options part, if present.
-
- 8.2 Fixed Part
-
- 8.2.1 General
-
- The fixed part contains frequently occurring parameters including the
- type code (ESH, ISH, or RD) of the protocol data unit.The length and
- the structure of the fixed part are defined by the PDU code.
-
-
-
-
-
-
-
-
-
-
-
-
- ISO N4053 [Page 26]
-
- RFC 995 December 1986
-
-
- The fixed part has the following format:
-
- Octet
- ________________________________________
- | Network Layer Protocol Identifier | 1
- |______________________________________|
- | Length Indicator | 2
- |______________________________________|
- | Version/Protocol Id Extension | 3
- |______________________________________|
- | reserved (must be zero) | 4
- |______________________________________|
- | 0 |0 |0 | Type | 5
- |___|__|__|____________________________|
- | Holding Time | 6,7
- |______________________________________|
- | Checksum | 8,9
- |______________________________________|
-
- Figure 1: PDU Header -- Fixed Part
-
-
- 8.2.2 Network Layer Protocol Identifier
-
- The value of this field shall be 1000 0010.
-
- Temporary Note:
- The value 1000 0010 is provisional, pending resolution of the NLPID
- issue in SC6.
-
- This field identifies this Network Layer Protocol as ISO SC6/N4053,
- End System to Intermediate System Routing Exchange Protocol for use in
- conjunction with ISO 8473.
-
- 8.2.3 Length Indicator
-
- The length is indicated by a binary number, with a maximum value of
- 254 (1111 1110).The length indicated is the length of the entire PDU
- (which consists entirely of header, since this protocol does not car-
- ry user data) in octets, as described in clause 8.1. The value 255
- (1111 1111) is reserved for possible future extensions.
-
- 8.2.4 Version/Protocol Identifier Extension
-
- The value of this field is binary 0000 0001. This identifies a stan-
- dard version of ISO xxxx, End System to Intermediate System Routing
- Exchange Protocol for use in conjunction with ISO 8473.
-
-
-
-
-
-
-
- ISO N4053 [Page 27]
-
- RFC 995 December 1986
-
-
- 8.2.5 Type Code
-
- The Type code field identifies the type of the protocol data unit.
- Allowed values are given in table 4.
-
- _____________________________________________________
- | | Bits 5 4 3 2 1 |
- |____________|______________________________________|
- |____________|______________________________________|
- |ESH PDU | 0 0 0 1 0 |
- |____________|______________________________________|
- |ISH PDU | 0 0 1 0 0 |
- |____________|______________________________________|
- |RD PDU | 0 0 1 1 0 |
- |____________|______________________________________|
-
- Table 4: Valid PDU Types
-
- All other PDU type values are reserved.
-
- 8.2.6 Holding Time
-
- The Holding Time field specifies for how long the receiving Network
- entity should retain the configuration/routing information contained
- in this PDU. The receiving Network entity should discard any infor-
- mation obtained from this PDU from its internal state when the hold-
- ing time expires. The Holding time field is encoded as an integral
- number of micro-fortnights.
-
- 8.2.7 PDU Checksum
-
- The checksum is computed on the entire PDU header. A checksum value
- of zero is reserved to indicate that the checksum is to be ignored.
- The operation of the PDU Header Error Detection function (Clause
- 7.11) ensures that the value zero does not represent a valid check-
- sum. A non-zero value indicates that the checksum must be processed.
- If the checksum calculation fails, the PDU must be discarded.
-
- 8.3 Network Address Part
-
- 8.3.1 General
-
- Address parameters are distinguished by their location. The different
- PDU types carry different address parameters however.The ESH PDU car-
- ries a Source NSAP address (SA); the ISH PDU carries a Intermediate
- System Network entity Title (NET); and the RD PDU carries a Destina-
- tion NSAP address (DA), and possibly a Network Entity Title (NET).
-
- 8.3.2 NPAI (Network Protocol Address Information) Encoding
-
- The Destination and Source Addresses are Network Service Access Point
-
-
-
- ISO N4053 [Page 28]
-
- RFC 995 December 1986
-
-
- addresses as defined in ISO 8348/AD2, Addendum to the Network Service
- Definition Covering Network Layer addressing.The Network Entity Title
- address parameter is defined in clause 4.5. The Destination Address,
- Source Address, and Network Entity Title are encoded as NPAI using
- the binary syntax defined in clause 8.3.1 of ISO 8348/AD2.
-
- The address information is of variable length. Each address parameter
- is encoded as follows:
-
- _______________________________________________
- | Octet | Address parameter Length Indicator |
- | n | (e.g., 'm') |
- |________|____________________________________|
- | Octets | |
- | n + 1 | Address Parameter Value |
- | thru | |
- | n + m | |
- |________|____________________________________|
-
- Figure 2: Address Parameters
- 8.3.3 Source Address Parameter for ESH PDU
-
- The Source Address is the NSAP address of an NSAP served by the Net-
- work entity sending the ESH PDU. It is encoded in the ESH PDU as fol-
- lows:
-
-
- Octet
- ________________________________________
- |Source Address Length Indicator (SAL) | 10
- |______________________________________|
- | | 11
- : Source Address (SA) :
- | | m - 1
- |______________________________________|
-
- Figure 3: ESH PDU - Network Address Part
-
- 8.3.4 Network Entity Title Parameter for ISH PDU
-
- The Network entity Title parameter is the Network Entity Title of the
- Intermediate System sending the ISH PDU. It is encoded in the ISH PDU
- as follows:
-
-
-
-
-
-
-
-
-
-
-
- ISO N4053 [Page 29]
-
- RFC 995 December 1986
-
-
- Octet
- _______________________________________________
- |Network Entity Title Length Indicator (NETL) | 10
- |_____________________________________________|
- | | 11
- : Network Entity Title (NET) :
- | | m - 1
- |_____________________________________________|
-
- Figure 4: ISH PDU - Network Address Part
-
- 8.3.5 Destination Address Parameter for RD PDU
-
- The Destination Address is the NSAP address of a destination associ-
- ated with some NPDU being forwarded by the Intermediate System send-
- ing the RD PDU. It is encoded in the RD PDU as follows:
-
- Octet
- _____________________________________________
- |Destination Address Length Indicator (DAL) | 10
- |___________________________________________|
- | | 11
- : Destination Address (DA) :
- | | m - 1
- |___________________________________________|
-
- Figure 5: RD PDU - Network Address Part
-
-
- 8.4 Subnetwork Address Part
-
- The Subnetwork Address Part is present only in RD PDUs.It is used to
- indicate the subnetwork address of another Network entity on the same
- subnetwork as the End System (and Intermediate System) which may be a
- better path to the destination specified in the Network Address Part.
- The Subnetwork Address parameter is encoded in the same manner as the
- Network Address parameters.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- ISO N4053 [Page 30]
-
- RFC 995 December 1986
-
-
- 8.4.1 Subnetwork Address Parameter for RD PDU
-
- The Subnetwork Address Parameter is encoded in the RD PDU as fol-
- lows:
-
- Octet
- _______________________________________________
- |Subnetwork Address Length Indicator (BSNPAL) | m
- |_____________________________________________|
- | | m + 1
- : Subnetwork Address (BSNPA) :
- | | n - 1
- |_____________________________________________|
-
- Figure 6: ESH PDU - Address Part
-
- 8.5 Options Part
-
- 8.5.1 General
-
- The options part is used to convey optional parameters. The options
- part
- of the PDU header is illustrated below:
-
- Octet
- ___________________________________________________
- | | p
- : Options :
- | | q
- |__________________________________________________|
-
- Figure 7: All PDUs - Options Part
-
- If the options part is present, it may contain one or more parame-
- ters. The number of parameters that may be contained in the options
- part is constrained by the length of the options part, which is
- determined by the following formula:
-
- PDU Header Length - (length of fixed part + length of address
- part + length of segmentation part),
-
- and by the length of the individual optional parameters.
-
- Parameters defined in the options part may appear in any order. Du-
- plication of options is not permitted.Receipt of a PDU with an option
- duplicated must be treated as a protocol error.
-
-
-
-
-
-
-
-
- ISO N4053 [Page 31]
-
- RFC 995 December 1986
-
-
- The encoding of parameters contained within the options part of the
- PDU header is illustrated below in figure 8.
-
- Octets
- _________________________________
- | n | Parameter Code |
- |____________|__________________|
- | n + 1 | Parameter Length |
- |____________|__________________|
- | n + 2 | |
- | to | Parameter Value |
- | n + m + 1 | |
- |____________|__________________|
-
- Figure 8: Encoding of Option Parameters
-
- The parameter code field is coded in binary and, without extensions,
- provides a maximum of 255 different parameters. No parameter codes
- use bits 8 and 7 with the value 00, so the actual maximum number of
- parameters is lower. A parameter code of 255 (binary 1111 1111) is
- reserved for possible future extensions.
-
- The parameter length field indicates the length, in octets, of the
- parameter value field.The length is indicated by a positive binary
- number, m, with a theoretical maximum value of 254. the practical
- maximum value of m is lower. For example, in the case of a single
- parameter contained within the options part, two octets are required
- for the parameter code and the parameter length indicators. Thus, the
- value of m is limited to:
-
- m = 252-(length of fixed part +length of address part
- +length of segmentation part )
-
- For each succeeding parameter the maximum value of m decreases. The
- parameter value field contains the value of the parameter identified
- in the parameter code field.
-
- The following parameters are permitted in the options part.
-
- 8.5.2 Security
-
- The Security parameter conveys information about the security re-
- quested in the Data PDU that caused the containing RD PDU to be gen-
- erated. This parameter has the same encoding and semantics as the
- Security parameter in ISO 8473.
-
- Parameter Code: 1100 0101
-
- Parameter Length: variable
-
- Parameter Value: See Section 7.5.3 of ISO 8473
-
-
-
- ISO N4053 [Page 32]
-
- RFC 995 December 1986
-
-
- 8.5.3 Quality of Service Maintenance
-
- The Quality of Service parameter conveys information about the quali-
- ty of service requested in the Data PDU that caused the containing RD
- PDU to be generated.
-
- This parameter has the same encoding and semantics as the QoS Mainte-
- nance parameter in ISO 8473.
-
- Parameter Code: 1100 0011
-
- Parameter Length: variable
-
- Parameter Value: See Section 7.5.6 of ISO 8473
-
- 8.5.4 Priority
-
- The Priority parameter conveys information about the priority re-
- quested in the Data PDU that caused the containing RD PDU to be gen-
- erated.
-
- This parameter has the same encoding and semantics as the Priority
- parameter in ISO 8473.
-
- Parameter Code: 1100 1101
-
- Parameter Length: one octet
-
- Parameter Value: See Section 7.5.7 of ISO 8473
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- ISO N4053 [Page 33]
-
- RFC 995 December 1986
-
-
- 8.6 End System Hello (ESH) PDU
-
- 8.6.1 Structure
-
- The ESH PDU has the following format:
-
- Octet
- ____________________________________________
- | Network Layer Protocol Identifier | 1
- |__________________________________________|
- | Length Indicator | 2
- |__________________________________________|
- | Version/Protocol Id Extension | 3
- |__________________________________________|
- | reserved (must be zero) | 4
- |__________________________________________|
- |0 |0 |0 | Type | 5
- |__|__|__|_________________________________|
- | Holding Time | 6,7
- |__________________________________________|
- | Checksum | 8,9
- |__________________________________________|
- | Source Address Length Indicator (SAL) | 10
- |__________________________________________|
- | | 11
- : Source Address (SA) :
- | | m - 1
- |__________________________________________|
- | | m
- : Options :
- | | p - 1
- |__________________________________________|
-
- Figure 9: ESH PDU Format
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- ISO N4053 [Page 34]
-
- RFC 995 December 1986
-
-
- 8.7 Intermediate System Hello (ISH) PDU
-
- 8.7.1 Structure
-
- The ISH PDU has the following format:
-
-
- Octet
- _______________________________________________
- | Network Layer Protocol Identifier | 1
- |_____________________________________________|
- | Length Indicator | 2
- |_____________________________________________|
- | Version/Protocol Id Extension | 3
- |_____________________________________________|
- | reserved (must be zero) | 4
- |_____________________________________________|
- |0 |0 |0 | Type | 5
- |__|__|__|____________________________________|
- | Holding Time | 6,7
- |_____________________________________________|
- | Checksum | 8,9
- |_____________________________________________|
- |Network Entity Title Length Indicator (NETL) | 10
- |_____________________________________________|
- | | 11
- : Network Entity Title (NET) :
- | | m - 1
- |_____________________________________________|
- | | m
- : Options :
- | | p - 1
- |_____________________________________________|
-
- Figure 10: ISH PDU Format
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- ISO N4053 [Page 35]
-
- RFC 995 December 1986
-
-
- 8.8 Redirect (RD) PDU
-
- 8.8.1 Structure
-
- The RD PDU has the following format:
-
- Octet
- ______________________________________________
- | Network Layer Protocol Identifier | 1
- |_____________________________________________|
- | Length Indicator | 2
- |_____________________________________________|
- | Version/Protocol Id Extension | 3
- |_____________________________________________|
- | reserved (must be zero) | 4
- |_____________________________________________|
- |0 |0 |0 | Type | 5
- |__|__|__|____________________________________|
- | Holding Time | 6,7
- |_____________________________________________|
- | Checksum | 8,9
- |_____________________________________________|
- | Destination Address Length Indicator (DAL)| 10
- |_____________________________________________|
- | | 11
- : Destination Address (DA) :
- | | m - 1
- |_____________________________________________|
- |Subnetwork Address Length Indicator (BSNPAL) | m
- |_____________________________________________|
- | | m + 1
- : Subnetwork Address (DBSNPA) :
- | | n - 1
- |_____________________________________________|
- |Network Entity Title Length Indicator (NETL) | n
- |_____________________________________________|
- | | n + 1
- : Network Entity Title (NET) :
- | | p - 1
- |_____________________________________________|
- | | p
- : Options :
- | | q - 1
- |_____________________________________________|
-
- Figure 11: RD PDU Format when Redirect is to an IS
-
-
-
-
-
-
-
-
- ISO N4053 [Page 36]
-
- RFC 995 December 1986
-
-
- Octet
- ______________________________________________
- | Network Layer Protocol Identifier | 1
- |_____________________________________________|
- | Length Indicator | 2
- |_____________________________________________|
- | Version/Protocol Id Extension | 3
- |_____________________________________________|
- | reserved (must be zero) | 4
- |_____________________________________________|
- |0 |0 |0 | Type | 5
- |__|__|__|____________________________________|
- | Holding Time | 6,7
- |_____________________________________________|
- | Checksum | 8,9
- |_____________________________________________|
- | Destination Address Length Indicator (DAL)| 10
- |_____________________________________________|
- | | 11
- : Destination Address (DA) :
- | | m - 1
- |_____________________________________________|
- |Subnetwork Address Length Indicator (BSNPAL) | m
- |_____________________________________________|
- | | m + 1
- : Subnetwork Address (DBSNPA) :
- | | n - 1
- |_____________________________________________|
- | NETL = 0 | n
- |_____________________________________________|
- | | n + 1
- : Options :
- | | p - 1
- |_____________________________________________|
- | Quality of Service | n + 1
- |_____________________________________________|
-
- Figure 12: RD PDU Format when Redirect is to an ES
-
-
- 9 Formal Description
-
- {Maybe next pass...}
-
- 10 Conformance
-
- See Clause 6.2.
-
-
-
-
-
-
-
- ISO N4053 [Page 37]
-
- RFC 995 December 1986
-
-
- ANNEX A. SUPPORTING TECHNICAL MATERIAL
-
-
- A.1 Use of Timers
-
- This protocol makes extensive use of timers to ensure the timeliness
- and accuracy of information disseminated using the Configuration and
- Route Redirection functions.This section discusses the rationale for
- using these timers and provides some background for how they operate.
-
- Systems using this protocol learn about other systems exclusively by
- receiving PDUs sent by those systems. In a connectionless environ-
- ment, a system must periodically receive updated information to en-
- sure that the information it previously received is still correct.
- For example, if a system on a subnetwork becomes unavailable (either
- it has ceased operating, or its SNPA becomes inoperative) the only
- way another system can detect this fact is by the absence of
- transmissions from that system. If information were retained in the
- absence of new PDUs being received, configuration and/or routing in-
- formation would inevitably become incorrect. The Holding Timers
- specified by this protocol guarantee that old information will not be
- retained indefinitely.
-
- A useful way of thinking of the configuration and route redirection
- information is as a cache maintained by each system. The cache is
- periodically flushed to ensure that only up-to-date information is
- stored.Unlike most caches, however, the time to retain information is
- not a purely local matter. Rather, information is held for a period
- of time specified by the source of the information. Some examples
- will help clarify this operation.
-
- A.1.1 Example of Holding Time for Route Redirection
-
- Route Redirection Information is obtained by an End System through
- the Request Redirect function (see clause 7.7).It is quite possible
- that a Intermediate System might redirect an End System to another IS
- which has recently become unavailable (this might happen if the IS-
- to-IS routing algorithm is still converging following a configuration
- change). If the Holding Timer were not present, or was set very long
- by the sending IS, an End System would have been redirected into a
- Black Hole from which none of its Data PDUs would ever emerge. The
- length of the Holding Timer on Redirects specifies, in essence, the
- length of time black holes are permitted to exist.
-
- On the other hand, setting the Holding Timer on Route Redirects very
- short to minimize the effect of black holes has other undesirable
- consequences.First, for each PDU that causes a redirect, an addition-
- al PDU beside the original Data PDU must be composed and transmitted;
- this increases overhead. Second, each time a "working" redirect's
- Holding Timer expires, the redirected End System will revert to a
- poorer route for at least one PDU.
-
-
-
- ISO N4053 [Page 38]
-
- RFC 995 December 1986
-
-
- A.1.2 Example of Holding Timer for Configuration Information
-
- A similar type of problem can occur with respect to Configuration in-
- formation. If the Holding Time of a ISH PDU (see clause 7.2.2) is set
- very long, and the only Intermediate System (which has been sending
- this Configuration Information) on the subnetwork becomes unavail-
- able, a subnetwork-wide black hole can form. During this time, End
- Systems on the subnetwork may not be able to communicate with each
- other because they presume that a Intermediate System is operating
- which will forward their Data PDUs to destination ESs on the local
- subnetwork and return RD PDUs.Once the Holding Time expires, the ESs
- will realize that no IS is available and will take their only
- recourse, which is to send their traffic directly on the local sub-
- network.
-
- Given the types of problems that can occur, it is important that
- responsibility for incorrect information can be unambiguously as-
- signed to the source of the information. For this reason all Holding
- Timers are calculated by the source of the Configuration or Route
- Redirection information and communicated explicitly to each recipient
- in the appropriate PDU.
-
- A.2 Refresh and timeout of Redirection information
-
- The protocol allows End Systems to refresh redirection information
- without first allowing the holding time to expire and being redirect-
- ed by a Intermediate System for a second (or subsequent) time. Such
- schemes are prevalent in connectionless subnetworks and are often
- called "reverse path information", "previous hop cache" or something
- similar.
-
- Refreshing the redirection information has obvious performance bene-
- fits, but can be dangerous if not handled in a very conservative
- fashion. In order for a redirection to be safely refreshed, all of
- the following conditions must hold:
-
- 1. The source address of the received PDU must be exactly the same
- as the destination address specified in a prior RD PDU (this
- defines a "match" on the redirection information). Making
- assumptions about the equivalence of abbreviated addresses,
- group addresses, or similar "special" addresses is dangerous
- since routing for these addresses cannot be assumed to be
- the same.
-
- 2. The Quality of Service parameters of the received PDU must be
- exactly the same as the QoS parameters specified in the matching
- (by destination address) redirection entry.Again, there is no
- guarantee that PDUs with different QoS parameters will be routed
- the same way. It is quite possible that the redirected path is
- even a black hole for certain values of the QoS parameters (the
- security field is a good example).
-
-
-
- ISO N4053 [Page 39]
-
- RFC 995 December 1986
-
-
- 3. The "previous hop" of the received Data PDU must match the "next
- hop" stored in the redirection information. Specifically, the
- SN_Source_Address of the SN_UNITDATA.Indication which received the
- PDU must match exactly the SN_Destination_Address specified in the
- redirect to be used for sending traffic via the SN_UNITDATA.Request
- primitive. This comparison ensures that redirects are refreshed only
- when the reverse traffic is being received from the same IS (or
- destination ES) as the forward traffic is being sent through (or
- to). This check make certain that redirects are not refreshed for
- just on the basis of traffic being received from the destination.
- It is quite possible that the traffic is simply indicating that the
- forward path in use is not working!
-
- Note that these conditions still allow refresh in the most useful and
- common cases where either the destination is another ES on the same
- subnetwork as the source ES, or the redirection is to a IS which is
- passing traffic to/from the destination in both directions (i.e. the
- path is symmetric).
-
- A.3 System Initialization Considerations
-
- This protocol is designed to make the exchange of information as free
- as possible from dependencies between the two types of systems.
- therefore, it is not possible for an End System to request all Inter-
- mediate Systems on a subnetwork to report their configuration, nor is
- it possible for an Intermediate System to request all End Systems on
- a subnetwork to report their configuration.
-
- In certain operating environments a constraint may be imposed than an
- ES, upon becoming operational, must discover the existence of an IS
- as soon as possible.The converse relationship also holds if it is
- necessary for an IS to discover the existence of End Systems as soon
- as possible. In both cases the availability of this information is
- normally determined by the Configuration Timer of the system for
- which the knowledge is desired. there is therefore a tradeoff between
- the overhead associated with performing the Report and Record Confi-
- guration functions and the timely availability of the configuration
- information. Decreasing the Configuration Timer increases the availa-
- bility at the expense of an increase in overhead.
-
- The following solution is recommended for addressing the constraint
- described above. When the Record Configuration function is invoked in
- either an End System or an Intermediate System, the function will
- determine if the received configuration information was previously
- unknown.If this is the case, then the Report Configuration function
- may be invoked before the expiration of the system's Configuration
- Timer. The Hello PDU generated by the Report Configuration function
- is then sent only to the Network Entity whose configuration was pre-
- viously unknown. Thus when an ES or IS first becomes operational it
- immediately reports its configuration. As soon as systems of the oth-
- er type discover the new network entity, they will make their own
-
-
-
- ISO N4053 [Page 40]
-
- RFC 995 December 1986
-
-
- configuration known to this entity.
-
- The additional overhead incurred by this solution is minimal. Also,
- since the discovery of new configurations is made timely by this ap-
- proach the Configuration Timer period can be increased in order to
- decrease the overhead of the configuration functions, provided that
- other factors not discussed here are accounted for by the longer time
- period.One caveat is that the first Hello PDU generated by a system
- may be lost during transmission. To solve this problem one or more
- additional PDUs may be transmitted at short time intervals during
- this initialization period.
-
- Note that this solution may be implemented in ISs only, in ESs only,
- or in both Intermediate and End Systems.This decision is purely a lo-
- cal matter and may be alterable through System Management.
-
- A.4 Optimizations for Flushing Redirects
-
- An ES will attempt to forward NPDUs through an IS to which it has
- been redirected until the Holding Timer specified in the RD PDU has
- expired, even if that IS is no longer reachable. Under certain cir-
- cumstances, it is possible to do better and recognize the existence
- of a black hole sooner. In particular, if the ES expects to hear ISH
- PDUs from the IS to which it has been redirected, and the Holding Ti-
- mer for that IS expires, all knowledge of the IS may be forgotten by
- the ES. This includes any redirects, which may be flushed (see the
- Flush Old Redirect function) even though their timeouts have not ex-
- pired.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- ISO N4053 [Page 41]
-
-